System and method for linking and managing linked orders in an electronic trading environment

ABSTRACT

A system and method for linking and managing linked orders are described. According to one method, a trader may first link two or more orders into a linked order, and then one or more parameters associated with one of the orders may be dynamically changed based on user inputs or information being received from an exchange. For example, a trader may link any two orders as an order cancel order, and each linked order may be associated with the same or different tradable objects, order quantities, and may be submitted to one or more exchanges. The order quantities may be then dynamically updated based on updates being received from the one or more exchanges and further based on a quantity ratio between the two orders. Further, the linked order may be submitted upon detecting a fill for another order.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/938,190, filed on Nov. 2, 2010, which is a continuation of U.S.patent application Ser. No. 11/415,949, filed on May 2, 2006, now U.S.Pat. No. 7,848,994, which is a continuation of U.S. patent applicationSer. No. 10/356,277, filed on Jan. 31, 2003, now U.S. Pat. No.7,844,536, entitled “System and Method for Linking and Managing LinkedOrders in an Electronic Trading Environment,” the contents of each ofwhich are fully incorporated herein by reference for all purposes.

FIELD OF INVENTION

The present invention is directed towards electronic trading. Morespecifically, the present invention is directed to tools for tradingtradeable objects that can be traded with quantities and/or prices.

BACKGROUND

Trading methods have evolved from a manually intensive process to atechnology enabled, electronic platform. With the advent of electronictrading, a user or trader can be in virtually direct contact with themarket, from practically anywhere in the world, performing nearreal-time transactions, and without the need to make personal contactwith a broker. Sometimes, electronic trading systems are also convenientfor brokers or other market participants on the floor at an exchange forreceiving market information.

Electronic trading is generally based on a host exchange, one or morecomputer networks, and client devices. In general, the host exchangeincludes one or more centralized computers to form the electronic heart.Its operations typically include order matching, maintaining order booksand positions, price information, and managing and updating a databasethat records such information. The host exchange is also equipped withan external interface that maintains uninterrupted contact to the clientdevices and possibly other trading-related systems.

Using client devices, market participants or traders link to the hostexchange through one or more networks. A network is a group of two ormore computers or devices linked together. There are many types of wiredand wireless networks such as local area networks and wide areanetworks. Networks can also be characterized by topology, protocol, andarchitecture. For example, some market participants may link to the hostthrough a direct connection such as a T1 or ISDN. Some participants maylink to the host exchange through direct connections and through othercommon network components such as high-speed servers, routers, andgateways. The Internet, a well-known collection of networks andgateways, can be used to establish a connection between the clientdevice and the host exchange. There are many different types of networksand combinations of network types known in the art that can link tradersto the host exchange.

Regardless of the way in which a connection is established, softwarerunning on the client devices allows market participants to log onto oneor more exchanges and participate in at least one market. A clientdevice is a computer such as a personal computer, laptop computer,hand-held computer, and so forth that has network access. In general,client devices run software that creates specialized interactive tradingscreens. Trading screens enable market participants to obtain marketquotes, monitor positions, and submit orders to the host.

Generally, when an order is submitted to a host exchange, the hostchecks the limits of the order, for example price and quantity, andprioritizes the order with other orders of the same price. When buy andsell order prices cross in the market, a trade occurs and information ofwhich is then relayed in some fashion to the client devices. In fact,the host exchange publishes a data feed to the client devices so thatthe traders can have access to the most current market information.

Market information commonly includes information regarding the insidemarket and market depth. The inside market is the lowest sell price inthe market and the highest buy price in the market at a particular pointin time. Market depth refers to quantity available at the inside marketand can refer to quantity available at other prices away from the insidemarket. The quantity available at a given price level is usuallyprovided by the host exchange in aggregate sums. In other words, a hostexchange usually provides the total buy or the total sell quantityavailable in the market at a particular price level in its data feed.The extent of the market depth available to a trader usually depends onthe host exchange. For instance, some host exchanges provide marketdepth for an infinite number of price levels, while some provide onlyquantities associated with the inside market, and others may provide nomarket depth at all. Additionally, host exchanges can offer other typesof market information such as the last traded price (LTP), the lasttraded quantity (LTQ), and/or order fill information.

To profit in electronic markets, however, market participants must beable to assimilate large amounts of data, including market information,and react to the received data more quickly than other competing marketparticipants. It is therefore desirable to offer tools that can assist amarket participant to make desirable trades at the most favorable pricesin a speedy and accurate manner.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention are described herein with referenceto the following drawings, in which:

FIG. 1 is an example of a network configuration for a communicationsystem utilized to access one exchange;

FIG. 2 is an example of a network configuration for a communicationsystem utilized to access two or more exchanges;

FIG. 3 is a simplified block diagram of a synthetic order manager forprocessing synthetic orders according to one example embodiment;

FIGS. 4A and 4B are a flow chart illustrating a method for processingsynthetic orders according to one example embodiment;

FIGS. 5A and 5B are a flow chart illustrating a method for updating andlocking records associated with synthetic orders on a data store entityupon detecting a trigger associated with a synthetic order according toone example embodiment; and

FIGS. 6A and 6B are a flow chart illustrating a method for updatingsynthetic orders records based on updates provided by an exchangeaccording to one example embodiment;

FIG. 7 is a flow chart illustrating a method for processing and managingtwo linked orders, forming an OCO pair, that are submitted to twoexchanges according to one embodiment; and

FIGS. 8A and 8B are a flow chart illustrating a method for linking morethan two orders and conditional submission of the order to one or moreexchanges according to one embodiment.

DETAILED DESCRIPTION

It is beneficial to allow a trader to link two or more orders, submitthe orders to one or more exchanges and dynamically manage the orders ata centralized module without requiring the trader's interaction.According to one preferred embodiment, a trader may link two or moreorders to form an order cancel order (“OCO”) pair, and then may submitthe two orders to a single or to different exchanges. In such anembodiment, a synthetic order manager associated with a gateway or anyother network entity may track any updates related to the submittedorders, such as partial order fills related to one of the orders andthen dynamically update, e.g., decrease or cancel, the order quantityassociated with the second order based on the received updates and aquantity ratio between the two orders.

For example, the two linked orders may have different quantities and maybe associated with two different tradable objects. In such anembodiment, when a partial fill is received for one of the orders, thesynthetic order manager may cancel an order quantity associated with thesecond linked order based on the ratio between the two order and furtherbased on the filled order quantity. For example, if an initial quantityratio between two orders is 2:1, e.g., the quantities of 20 and 10 areassociated with the two orders, and the quantity of 4 gets filled forthe first order, the synthetic order manager may decrease the orderquantity of the second order by 2.

Further, according to another embodiment, a linked order pair of an OCOassociated with the same or different tradable objects and having thesame of different order quantities, for example, may be submitted to oneor more exchanges upon detecting a predetermined condition associatedwith another order. In such an embodiment, a buy order may be linked toa sell OCO pair, according to an example embodiment, including a sellstop order and a sell limit order, for example. When the buy order ispartially filled, for example, the sell OCO pair, having the orderquantities determined based on the partial fill of the buy order, may besubmitted to one or more exchanges. More OCO pairs may be subsequentlysubmitted upon detecting additional fills related to the buy order.

Further, according to another embodiment, a trader may link any two ormore orders, and any changes applied to one of the linked orders'parameters may be dynamically reflected in other linked orders. Forexample, if one of the linked orders is deleted, the other linked ordersmay be dynamically deleted as well. It should be understood that, ifmore than two orders are linked, a trader may configure which of thelinked orders should be deleted upon receiving a user input deleting oneof the linked orders. While the present invention is describedhereinafter with reference to illustrative embodiments for particularapplications, it should be understood that the present invention is notlimited thereto. Those having ordinary skill of art will recognize thatmany additional modifications and embodiments are possible as well.

FIG. 1 shows an example system that may be used to implement a networkfor processing linked orders in an electronic trading environment inaccordance with a preferred embodiment. It should be understood,however, that this and other arrangements described herein are set forthfor purposes of example only. As such, those skilled in the art willappreciate that other arrangements and other elements (e.g., machines,interfaces, functions, orders of function, etc.) can be used instead,and some elements may be omitted altogether. Further, as in mosttelecommunications applications, those skilled in the art willappreciate that many of the elements described herein are functionalentities that may be implemented as discrete or distributed componentsor in conjunction with other components, and in any suitable combinationand location.

Still further, many functions described herein as being performed by oneor more entities may be carried out by hardware, firmware, and/orsoftware logic. For instance, a processor executing a set of machinelanguage instructions stored in memory may execute various functions.Provided with the present disclosure, those skilled in the art canreadily prepare appropriate computer instructions to perform suchfunctions.

Referring back to FIG. 1, the illustrated system includes a hostexchange 100, a gateway 102, and a client terminal 104. It should beunderstood that even though the system illustrates only one clientterminal 104 communicating with a single host exchange 100, the clientterminal 104 could also communicate with more than one host exchange viathe gateway 102 or multiple gateways. Further, it should be understoodthat the example system is not limited to a single client terminal. Inan alternative embodiment, a trading house including a plurality ofclient terminals may connect to the host exchange 100 via the gateway102.

The host exchange 100 may be any electronic exchange including theChicago Board of Trade (“CBOT”), the New York Stock Exchange (“NYSE”),the Chicago Mercantile Exchange (“CME”), Xetra (a German stockexchange), or the European derivatives market (“Eurex”). However, itshould be understood that the exchanges could also include any otherexisting or later developed exchanges. Further, it should be understoodthat the preferred embodiments are not limited to any particular networkarchitecture or trading application, but rather may be applied withutility in any network that can be used for electronic trading.Furthermore, the invention is not limited to a completely electronictrading environment where orders are sent to an electronic matchingengine. For example, the invention could be utilized with an electronictrading application, which sends orders electronically to a terminalwhere a person (e.g., a floor broker) executes those orders in atraditional open outcry trading floor.

The host exchange 100 connects to the client terminal 104 via thegateway 102. The gateway 102, as is known in the art, may include one ormore computers, or software programs, and receives information from thehost exchange 100 and sends the information down to the client terminal104. The host exchange 100 provides market information to the gateway102 and relays this information, or a portion thereof, collectivelycalled a data feed 106, over a network to market participants at theclient terminal 104. A data feed from one exchange may contain differentinformation representing different tradable objects than another datafeed from a second exchange. In one embodiment, a data feed may includemarket information related to all tradable objects being traded at theexchange 100. In such an embodiment, when the client terminal 104receives such a data feed, a trading application on the client terminal104 may extract, from the received data feed, information related to oneor more tradable objects selected by a user at the client terminal 104.Alternatively, the gateway 102 could be configured to extract theinformation related to tradable objects selected by a particular user atthe client terminal 102. Further, alternatively, the host exchange 100may have knowledge of tradable object(s) that were selected by a user atthe client terminal 104, and may provide to the client terminal 104 onlymarket data related to the selected tradable objects.

As used herein, the term “tradable object” refers simply to anythingthat can be traded with a quantity and/or price. It includes, but is notlimited to, all types of tradable objects such as financial products,which can include, for example, stock options, bonds, futures, currency,and warrants, as well as funds, derivatives, and collections of theforegoing, and all types of commodities, such as grains, energy, andmetals. The tradable object may be “real,” such as products that arelisted by an exchange for trading, or “synthetic,” such as a combinationof real products that is created by a user. Also, a tradable objectcould actually be a combination of other tradable objects, such as aclass of tradable objects.

The data feed 106 may include information relating to prices andquantities of one or more tradable objects. For example, the data feed106 could provide data corresponding to quantities at inside marketprices and/or data corresponding to quantity at different prices. Theinside market is the best bid price (“BBP”) and the best ask price(“BAP”) for a tradable object. Data feeds from some exchanges may alsoprovide data related to the market depth.

According to one embodiment, each exchange, such as the exchange 100,could be associated with one gateway. When a trader wants to participatein the market at one of the two exchanges, for example, the trader cansubscribe to the data feed corresponding to that exchange. If the traderthen decides to add the second exchange, the trader may do so at anytime. In another embodiment, more than one host exchange may send a datafeed to a single gateway. Referring to the example above, each of thetwo exchanges could send its data to the single gateway. Then, if atrader wants to participate at the two exchanges, the trader maysubscribe, at the gateway, to the data feeds corresponding to theselected exchanges. In yet another embodiment, some exchanges may havemultiple gateways. For example, the two exchanges may be associated withthree gateways each.

The client terminal 104 may include any computing terminal, such as apersonal computer, a handheld device, or any other currently existing orlater developed computing terminal. The client terminal 104 may connectto the gateway 102 via one or more wireless communication links,wireline communication links, or a combination thereof. In general,according to one embodiment, the client terminal 104 is a computer thatallows a trader to participate in the market hosted at the exchange 100,and uses software that creates specialized trading screens on the clientterminal 104. Among other functional features, a trading screen beingrun on the client terminal 104 may enable traders to enter and executeorders, obtain market quotes, and monitor positions. However, it shouldbe understood that, in addition to interactive trading screens, theclient terminal 104 may also run automated non-interactive types oftrading applications.

A commercially available trading application that allows a user to tradein a system like the one shown in FIG. 1 is X_TRADER® from TradingTechnologies International, Inc. of Chicago, Ill. X_TRADER® alsoprovides an electronic trading interface, referred to as MD Trader™, inwhich working orders and/or bid and ask quantities are displayed inassociation with a static axis of prices. However, the preferredembodiments are not limited to any particular product that performstranslation, storage and display functions.

The gateway 102 can be a computer of any size such as a server,workstation, personal computer, or any network entity having theprocessing power to perform functions described herein. Also, it shouldbe understood that the functions performed on the gateway 102 can bemoved or load-balanced between a plurality of network entities.

As illustrated in FIG. 1, the gateway 102 includes a translator module108, a synthetic order manager (“SOM”) 110, and a core applicationprogram interface (“API”) 112. It should be understood that in analternative embodiment, the SOM 110 may be collocated with a clientterminal or may be a separate network entity in communication with thegateway 102, for example. The translator module 108 performs protocolconversions between data that is sent to and from the client terminal104 and the exchange 100. For example, when the gateway 102 receives adata feed 106 from the exchange 100, the translator module 108 may useconversion techniques known in the art to convert the received data to aformat compatible with the protocols employed at the client terminal104. Similarly, when the gateway 102 receives data from the clientterminal 104, such as new order data, the translator module 108 convertsthe received data to a format compatible with the protocols used at theexchange 100.

Among other functions, the core API 112 may hold the current state ofthe system, perform user authorization, or monitor which clientterminals and users are connected to the system. For example, when thegateway 102 receives the data feed 106, the core API 112 may determineif the client terminal 104 is authorized to receive data from theexchange 100, and, upon a successful authorization, the converted datamay be sent to the client terminal 104.

Further, as mentioned in the preceding paragraph, the gateway 102includes the SOM 110 that is configured to process linked order sets,where each order set may include two or more linked orders describedfurther below. According to one embodiment, a trader may link any two ormore orders, and the SOM 110 may process and control order parametersbased on any user configurations. The linked orders may includeconditional orders, e.g., orders that are submitted to an exchange upondetecting one or more conditions triggering the submission of one ormore linked orders to the exchange. For example, a triggering conditionmay include any market-related data condition, or any data related toone or more orders forming a linked order set, such as fill update dataor a detection of deletion of one or more orders forming the linkedorder set. However, it should be understood that the present inventionis not limited to such linked orders, and any two orders of the same ordifferent quantities, tradable objects, order types, and any two orderssubmitted to the same or different exchanges, may be linked to form alinked order set.

According to one embodiment, the SOM 110 may be implemented using one ormore servers that are arranged to support processing of linked ordersets and monitoring triggers associated with the orders. Generally, aserver is a computer or program that responds to commands from a clientterminal. FIG. 1 illustrates the SOM 110 as part of the gateway 110.However, it should be understood that the SOM 110 may be implementedusing one or more network servers in communication with one or moregateways, such as the gateway 112. The SOM 110 also communicates withthe data store entity 114 that provides a central storage means for datarelated to linked orders. It should be understood that the data storeentity 114 does not have to be a separate entity and, in an alternativeembodiment, the data store entity 114 may be collocated with the SOM110. The data store entity 114 may include a database, a network server,or any other network entity capable of storing data. In addition tostoring order status information, the data store entity 114 storesgeneral information related to linked orders. For instance, each linkedorder record may define which orders have been linked, conditionstriggering submission of one or more linked orders to an exchange, aswell as rules for processing orders.

According to one embodiment, and as mentioned in the precedingparagraphs, conditions related to linked orders may include market datarelated event conditions or any other user configurable events that maytrigger submission of one or more linked orders to the exchange.Further, the SOM 110 may dynamically submit orders to an exchange, andprices of the orders may be based upon the position of the market. Inone embodiment, a trader may specify a tick value away from the insidemarket based on which an order may be submitted to the exchange. Forexample, a market maker may decide to configure a buy and sell order tobe sent to the exchange at minus/plus two ticks from the inside market.In such an embodiment, every time a fill associated with one of theorders occurs, the SOM 110 may place another order to the exchange basedon the predefined tick value so that the trader always has a working buyand a sell order on the market.

Further, the data store entity 114 may include records associated withthe current status of each order. For example, when the gateway 102receives an order request associated with a linked order, order-relateddata, such as an order identifier for each linked order and any otherorder related data such as an exchange identifier associated with anexchange to which each order should be sent, may be stored in the datastore entity 114. For example, upon receiving a linked order set, a neworder record may be created in the data store entity 114 for thereceived linked order set. The record may then be tagged with apredetermined identifier indicating the status of each order that hasbeen linked. For example, if one of the linked orders is to beactivated, e.g., sent to an exchange upon detecting a predeterminedcondition, the order may be first tagged with a pending identifier.Then, for example, once the predetermined condition is detected, and theorder is submitted to an exchange, the pending order identifier may beupdated to an active identifier.

According to a preferred embodiment, the data store entity 114 may serveas a central locking location so that, for instance, when two or moreSOMs receive data related to the same order, such as an order updaterelated to fill information, only the SOM that accesses the data storeentity 114 first will be able to update the record related to the order,thus, effectively “locking” the same information from being updated morethan once. It should be understood that different locking means could beused. For instance, when the first SOM updates a specific record in thedata store entity 114 based on the update received from the exchange,for example, the first SOM could insert into the record a predeterminedidentifier indicating that the record has been already updated. Such anembodiment is especially useful when two traders in the same group arelogged on two different gateways, and both gateways receive updates,such as fill updates, for the same order. When the updates are receivedon the two SOMs, the SOMs will attempt to update the same order recordon the data store entity 114. However, using the locking mechanismdescribed above, when the first SOM accesses the record first, it willeffectively lock the record preventing the second SOM from updating thesame information more than once.

Further, it should be understood that, upon starting-up the gateway 102,and upon detecting that a trader has logged into the gateway 102, theSOM 110 may query the data store entity 114 for all synthetic ordersassociated with that trader. Based on that information, the SOM 110 mayupdate its internal list of triggers to be monitored for the syntheticorders associated with the trader. Additionally, it should be understoodthat when the SOM 110 loses its connectivity to the data store entity114, the SOM 110 may put all synthetic orders on hold until theconnectivity is restored. When an order is put on hold, the order mayeffectively be deleted from the exchange, and the information related tothe order may be stored in an order book either on a client terminal ora gateway. In such an embodiment, when a trader reactivates the orderthat has been put on hold by selecting a predetermined user selectioninput, for example, the order information may be retrieved from theorder book, and the order may be resubmitted to the exchange.

FIG. 2 is a block diagram illustrating an example system 200 that may beused to implement a network for processing linked orders in anelectronic trading environment, in which linked orders are sent to twodifferent exchanges. The illustrated system 200 illustrates the clientterminal 104, a gateway 214 including the SOM 110 communicating with thedata store entity 114, the core API 112, and the translator 108 thathave been described in reference to FIG. 2. The gateway 214 may furthercommunicate with two other gateways 210 and 212 enabling a trader tosubmit two or more orders being linked as an linked order set to twodifferent exchanges 202 and 204 providing data feeds 206 and 208,respectively. It should be understood that the embodiments describedhereinafter and related to synthetic orders and linked orders may beimplemented using any system and are not limited to two exchanges. Forexample, and as will be described in greater detail below, a trader maylink three orders that may be submitted to three different exchanges. Insuch an embodiment, when a fill associated with a first order isdetected, two other linked orders, having order quantities equal to thedetected fill, may be submitted as an OCO order pair to two differentexchanges.

Further, as illustrated in FIG. 2, each gateway 210 or 212 may beassociated with another SOM in communication with the SOM 110 on thegateway 214. In such an embodiment, the functionality of the SOM may bedistributed between the SOM 110, and the SOMs located on the gateways210 and 212.

FIG. 3 is a simplified block diagram of an example SOM 110 that may beused for processing and managing linked orders according to one exampleembodiment. The SOM includes a memory unit 302, a processor 304, anorder application 306, a data store interface 308, and a bus 310 thatlinks all components of the SOM 110. The order application 306 allowsusers to link any two or more orders and to manage such orders.

The memory unit 302 may include any type of memory means including arandom access memory, read only memory, or another appropriate storagemedium. The processor 304 may include any existing or later developedprocessing unit. It should be understood that the application programsof the order application 306 can be stored in the memory unit 302. Thedata store interface 308 provides means for communicating data betweenthe SOM 110 and the data store entity 114.

According to one embodiment, when the gateway 102 receives an order, thesynthetic order application 306 may determine if the order is asynthetic order. According to one embodiment, the synthetic orderapplication 306 may determine if an incoming order is a synthetic orderbased on a predetermined identifier attached to the order, or based onorder parameters, such as order triggers specified in the order. Thesynthetic order application 306 may make that determination based ondata available in the memory unit 302 or by querying the data storeentity 114. If the incoming order is a synthetic order, the syntheticorder application 114 may then determine if the exchange to which theorder should be sent supports this type of order. Once again, thesynthetic order application 306 may make that determination based ondata available at the data store entity 114 or based on data in its ownmemory unit. If the exchange supports the specified type of syntheticorder, the SOM 110 may forward the order request to the translator 108,which, responsively, may translate the order to a protocol format usedat the exchange, and the gateway 102 may forward the order to theexchange.

However, if the synthetic order application 306 determines that theexchange does not support the requested synthetic order, the gateway 102does not forward the order to the exchange. Instead, the synthetic orderapplication 306 may determine triggering events that are associated withthe order. In one embodiment, the gateway 102 may offer a number ofstandard synthetic orders having one or more preset triggering events. Astandard synthetic order is a synthetic order associated with one ormore preset triggering events, where a trader may specify any desirablevalues for the preset triggering events. For instance, if a triggeringevent is a price trigger, a trader may enter a desirable price level atwhich the order should be triggered, and then submitted to an exchange.Alternatively, instead of providing standard synthetic orders havingpreset triggering events, the gateway 102 may provide a number oftriggering events that are supported by the SOM 110, and a trader mayuse the provided triggering events to create his own synthetic order,i.e., a user configurable synthetic order. It should be understood that,in one embodiment, a window interface or any other interface may beprovided to a trader, via which the trader may select a predeterminedstandard synthetic order, or create his own synthetic order based on thetriggering events that are supported at the gateway 104.

Once the synthetic order application 306 determines the triggeringevents, the synthetic order application 306 may start monitoring thetriggering events associated with the order. For example, if atriggering event is based on a price of a tradable object, the syntheticorder application 306 may start monitoring price updates associated witha predetermined tradable object until a trigger price specified by auser is reached, thus triggering submission of the order to theexchange, the embodiments of which will be described in greater detailin reference to subsequent figures.

When the synthetic order application 306 detects one or more triggersassociated with a synthetic order, the gateway 102 may submit the orderto the exchange 100. However, before the gateway 102 submits the orderto the exchange 100, the synthetic order application 306 may append tothe order a synthetic order indicator. Preferably, the synthetic orderindicator is appended to a portion of the original order that is notmodified by the exchange. In such an embodiment, any synthetic orderrelated updates will include the identifier that has been appended bythe application 306 to the original order data. In such an embodiment,when the SOM 110 receives order updates from the exchange 100, the SOM110 may determine if the received update includes a synthetic orderindicator and thus whether the update is related to a synthetic order.If an update includes a synthetic order indicator, such an update may beforwarded to the synthetic order application 306 for processing. Theprocessing of the updates, among other functions, may include updatingof a status of a synthetic order specified in the update. Thus, such anembodiment allows for saving time on data reads to and from the datastore entity 114 as well as processing of non-synthetic orders.

FIGS. 4A and 4B are a flow chart illustrating a method 400 forprocessing synthetic orders according to one example embodiment. Themethod 400 will be described in relation to network entities describedin FIG. 1. However, it should be understood that the method 400 is notlimited to the network architecture or network entities illustrated inFIG. 1.

At step 402, the gateway 102 receives an order request from the clientterminal 104. When the core API 112 receives the order request, the coreAPI 112 may perform authorization of a trader associated with therequest. For example, among other authorization procedures, the core API112 may determine if a trader is authorized to receive market data, suchas price updates, associated with a tradable object specified in theorder request. In one embodiment, the authorization may be performedbased on the trader's identifier or a group identifier specified in theorder request. However, it should be understood that differentauthorization methods could also be used as well.

Upon successful authorization, the core API 112 may send the orderrequest to the SOM 110, which, at step 404, determines if the receivedorder request is associated with a synthetic order. It should beunderstood that the determination whether the order is a synthetic ordermay be performed in many ways. In one embodiment, the order request mayinclude an identifier that indicates whether the order is a syntheticorder. The SOM 110 may then determine if the identifier specified in therequest matches any identifiers associated with synthetic ordersprovided by the gateway 102. For example, the synthetic orderidentifiers may be stored on the SOM 110, in the SOM's memory unit 302.Alternatively, the data store entity 114 may store the identifiers, andthe SOM 110 may download the identifiers from the data store entity 114upon each start up. Alternatively, the SOM 110 may determine if theorder is a synthetic order request based on order parameters, other thanthe identifier defining the order as a synthetic order. For instance, ifthe order request includes a user configurable synthetic order, theorder request may specify one or more triggering events and values forthe events. In such an embodiment, the SOM 110 may determine if thereceived order request includes one or more triggering events associatedwith the synthetic orders. It should be understood that differentmethods for determining whether an order request is associated with asynthetic order could also be used. If the received order is not asynthetic order, the method continues at step 402, when the SOM 110 mayreceive a new order at step 402 and then determine if the order is thesynthetic order at step 404.

At step 406, the SOM 110 determines whether the type of the syntheticorder specified in the request is handled by an exchange associated withthe request. According to one embodiment, to make that determination,the SOM 110 may query the data store unit 114. As mentioned in thepreceding paragraphs, the data store unit 114 may store recordsincluding information related to types of orders that are handled ateach exchange. Alternatively, a record associated with each exchange mayspecify types of triggers that each exchange is capable of processing.In such an embodiment, the SOM 110 may query the data store entity 114to determine if the exchange to which the order should be sent supportsthe triggers associated with the synthetic order specified in therequest.

If the exchange supports the requested synthetic order, at step 408, thegateway 102 sends the order to the exchange. It should be understoodthat before sending the order to the exchange, the SOM 110 forwards theorder to the translator 108 that may translate the order parameters to aprotocol format used at the exchange. However, if the exchange does notsupport the requested synthetic order, at step 410, the SOM 110 may tagthe order with a synthetic order indicator so that the gateway 102 mayeasily distinguish which order updates that are received from theexchange correspond to the synthetic orders and require synthetic orderprocessing. To ensure that the exchange returns a synthetic orderindicator with any information related to the synthetic order, thesynthetic order indicator may be appended to one of the order fieldsthat are returned from the exchange with every response or fill updaterelated to that order. For instance, a synthetic order indicator may beappended to a site key field of an order. However, different embodimentsare possible as well. Thus, when the gateway 102 receives an orderupdate including a synthetic order indicator, the gateway 102 mayquickly determine that the update corresponds to one of the submittedsynthetic orders. Similarly, if the update does not include a syntheticorder indicator, the gateway 102 does not attempt to process updatesrelated to standard orders as updates related to synthetic orders, thus,saving time on data processing and reads from and reads to the datastore entity 114.

When the SOM 110 tags the order with the synthetic order identifier, atstep 412, the SOM 110 stores the order in the SOM's memory unit and thedata store entity 114. As mentioned in the paragraphs above, the datastore entity 114 may first create a record for the order and then markthe record with an order status identifier. Among many possibleidentifiers, the data store entity 114 may mark the order record with apending identifier, an active identifier, a pending trigger identifier,or a working order identifier, for instance. In one embodiment, if theSOM 110 determines that one of order triggering events is a price leveltriggering event, the SOM 110 may first determine if a trader issubscribed to a price feed associated with a tradable object in thesynthetic order. If the SOM 110 determines that the trader does notreceive the price feed associated with the tradable object, the ordermay be marked with a pending identifier, and the process of subscribingto a desired price feed may be initiated. Accordingly, when the processof subscribing to the price feed is successfully completed, the orderidentifier may be updated to an active order identifier.

Additionally, when the order is activated, the order may also be markedwith a pending trigger identifier indicating that the SOM 110 may startmonitoring triggering events associated with the order. Further, whenthe order is submitted to the exchange, the SOM 110 may mark the orderwith the working order identifier. However, it should be understood thatdifferent, more, fewer, or equivalent identifiers could be used instead.Further, it should be understood that the example embodiments are notlimited to determining if the trader's client terminal receives a pricefeed associated with a tradable object specified in the synthetic orderrequest. In other embodiments, a determination of other parameters orconditions may be made based on a triggering event associated with asynthetic order or based on other settings.

Upon marking the order with an active order identifier, the SOM 110 maystart monitoring one or more triggering events associated with thesynthetic order. According to an example embodiment, the SOM 110 maycreate a triggering event record including triggering events for allsynthetic orders marked with the pending trigger identifier. In such anembodiment, every time a new order is marked with a pending triggeridentifier, the triggering event associated with that order may be addedto the triggering event record. Such records may then be stored in thememory unit on the SOM 110. For example, if one or more synthetic orderstrigger based on a plurality of price levels, the triggering eventrecord may include a general trigger related to monitoring one or moreprice feeds associated with one or more synthetic orders, and aplurality of triggers within the general trigger identifying specificprice levels to be monitored. It should be understood that differentimplementations are possible as well.

Referring to FIG. 4B, at step 414, the SOM 110 determines if one or moretriggers associated with the synthetic order have been detected. Forexample, it should be understood that a synthetic order may be triggeredbased on one triggering event or based on a number of triggering events.In one embodiment, a user may configure a synthetic order to triggerbased on a multilevel trigger, i.e., a trigger including a plurality ofsub-triggers that may be checked in a predetermined user-configurableorder. For example, a first trigger may include a predetermined pricerange that, when satisfied, may activate the process of monitoring asecond trigger such as a fill event on a different order, or vice versa.It should be understood that many different embodiments are possible aswell.

If the SOM 110 detects one or more triggers associated with thesynthetic order, at step 416, the SOM 110 may query the data storeentity 114 for any orders of traders logged onto the gateway 102 thatshould be activated based on the detected trigger. It should beunderstood that the triggered action may involve submitting of the orderto the exchange or, alternatively, may invoke monitoring of the nexttrigger associated with one or more orders. If one or more orders existthat should be submitted to the exchange when a specific trigger isdetected, the SOM 110 may access such order records on the data storeentity 114. As mentioned in the preceding paragraph, more than one SOMmay be involved in processing of the same set of orders. In such anembodiment, if the SOM 110 attempts to access an order record, and therecord is locked, the process terminates, since another SOM has alreadyaccessed the record and is working on submitting the order to theexchange.

If the SOM 110 is successful in accessing the order record, at step 418,the SOM 110 may submit the order to the translator 108 that maysubsequently translate the order to a protocol format used at theexchange. Then, the gateway 102 may start monitoring updates from theexchange 100. At step 420, the SOM 110 determines if any updates relatedto the submitted synthetic order have been received from the exchange100. As mentioned earlier, the SOM 110 may quickly determine if anupdate is related to a synthetic order based on whether the updateincludes a synthetic order indicator. Thus, if an order update includesa synthetic order indicator, the SOM 110 may determine that the updateis related to the synthetic order. If such a determination is made, theSOM 110 may then match the synthetic order indicator with a specificsynthetic order that has been submitted to the exchange.

If the order update relates to the submitted synthetic order, at step422, the SOM 110 may update the status of the order based on theinformation provided in the update. For instance, the update mayindicate that the order has been received at the exchange or that theorder has been filled. According to the preferred embodiment in whichthe data store entity 114 is a central storage entity for syntheticorders, the SOM 110 may access the data store entity 114 and update thestatus of the order in the record corresponding to the order. It shouldbe understood, and as will be described in reference to the subsequentfigure, if more than one gateway receives the order update, the SOM 110may first determine if the record associated with the order is unlocked,i.e., whether another SOM has not already accessed the data store entity114 and updated the order record. If the record is unlocked, the SOM 110may access the record and update the order status based on the updateinformation specified in the received update. For example, if the updatespecifies that the order quantity has been filled, the SOM 110 mayupdate the working order identifier to a filled order identifier. Itshould be understood that if the order is filled by the exchange, theSOM 110 may remove the triggering event associated with the order fromits list of triggering events. Finally, at step 424, the SOM 110 sendsthe order status data to the client terminal, and the method 400terminates.

According to a preferred embodiment, the data store entity 114 mayfunction as a centralized network entity and may track status ofsynthetic orders that are serviced at a plurality of gateways. Thecentralized functionality may be especially useful in a system in whichtwo or more traders in the same group are logged onto two or moregateways, and SOMs associated with the gateways may monitor triggeringevents, submit orders based on the occurrence of specific triggers forthe same set of orders, or update status of each such order. To preventmore than one gateway from submitting an order to the exchange when oneor more triggers are detected for the order by more than one gateway,each SOM may be configured to access the data store entity 114 andverify the status of the order before taking any action on the order.According to the preferred embodiment, the data store entity 114provides a locking mechanism that prevents more than one SOM from takingthe same type of action on a specific order. For instance, when morethan one SOM monitors the triggering events for the same syntheticorder, it is important that only one of the SOMs will be able to sendthe order to the exchange upon detecting one or more triggering eventsassociated with the order.

FIGS. 5A and 5B are a flow chart illustrating a method 500 for updatingand locking records associated with synthetic orders on the data storeentity 114. According to the method 500, more than one gateway andassociated SOMs may receive updates and submit orders related to thesame set of synthetic orders. More specifically, the method 500 relatesto monitoring triggering events associated with a predetermined set ofsynthetic orders on multiple SOMs.

At step 502, a plurality of SOMs detects one or more triggers associatedwith a synthetic order. For instance, the one or more triggers, whendetected, may trigger submission of an order to the exchange. At step504, the plurality of SOMs query the data store entity 114 to access anorder record of the synthetic order. It should be understood that eachSOM may detect one or more triggers at slightly different times, thus,affecting the time when each SOM queries the data store entity 114.According to a preferred embodiment, the first SOM which accesses theorder record may lock the order record or a portion thereof uponaccessing the record, thus, effectively preventing other SOMs thataccess the data store entity 114 at a later time from updating therecord based on the same trigger, or taking any actions that should beinitiated upon detecting the trigger.

When each of the plurality of SOMs accesses the data store entity 114,each SOM determines if the order record or a portion of the order recordassociated with the detected triggering event has been locked. Asmentioned earlier, an order record or a portion thereof may be lockedvia a number of means, and one of them may involve tagging the recordwith one or more identifiers preventing another SOM from accessing ormodifying a certain portion of the record when another SOM has alreadydone so. Thus, if the SOM determines that the order record or a relevantportion thereof has been locked, the method 400 terminates. However, ifthe SOM determines that there is no lock on the record, the SOM may takea certain action based on the detected trigger.

Thus, at step 508, the SOM may lock at least a portion or the entireorder record preventing another SOM from accessing or updating therecord. Referring to FIG. 5B, at step 510, the SOM may compare a desiredtrigger action with the current status of the order. For instance, if atrigger action requires the SOM to submit the order to the exchange oncethe one or more triggers have been detected, the SOM may first determineif the order is not expired before submitting the order to the exchange.In one embodiment, the order expiration date may be based on apredetermined user-configurable date such as a contract expiration date,or the end of a predetermined trading session, for instance.Alternatively, a user may configure specific dates defining when thesynthetic order can be submitted.

At step 512, the SOM determines if any action is required based on thedetected trigger. Among many possible actions, the one or more triggersmay activate submission of the associated synthetic order to theexchange or activation of a process involving monitoring of another setof triggers, such as in a multi-trigger synthetic order case, forinstance. If no action is required based on the detected trigger, themethod proceeds to step 516. However, if the triggers invoke apredetermined action, such as submission of the order to the exchange,at step 514, the SOM triggers such an action, and the order is submittedto the exchange. Next, upon completion of the action, the SOM updatesthe record that the action has been completed. For example, the SOM mayupdate the order status identifier to a working order identifierindicating that the order has been successfully submitted to theexchange, and the method 400 terminates.

FIGS. 6A and 6B are a flow chart illustrating a method 600 for updatingsynthetic order records based on updates provided by the exchange. Themethod 600 is described in reference to fill updates being received fromthe exchange. However, it should be understood that the fill updates areused only as an example, and any updates could be processed according tothe method 600.

At step 602, a gateway receives from an exchange a fill update relatedto a synthetic order. According to one embodiment, a SOM on the gatewaymay determine that the update is related to a synthetic order based on asynthetic order indicator included in the update, for instance. At step604, the SOM updates its memory records associated with the syntheticorder based on the fill information specified in the received fillupdate. Next, at step 606, the SOM accesses a record associated with asynthetic order on the data store entity, and, at step 608, the SOMdetermines if a fill lock has been applied to the record indicating thatanother SOM has already updated the record based on the fill update.Therefore, if the record data related to the received fill informationhas been already updated, the method 600 terminates. Otherwise, at step610, the SOM inserts the fill lock in the synthetic order record so thatno other SOM can access the record to update the same fill information.Next, at step 612, the SOM updates the fill order information in thesynthetic order record based on the fill information provided in thereceived update.

At step 614, the SOM may determine if a full order quantity has beenfilled. If the quantity has been filled only partially, the method 600may continue at step 602. However, if the order quantity has been fullyfilled, at step 616, the SOM may determine if the synthetic order is amulti-trigger synthetic order and if another action should be triggeredbased on the received fill update. If no such next level trigger exists,the method 500 terminates. If the SOM determines that the fill of thefull quantity triggers another action, at step 518, the SOM may initiateperforming such an action. For example, among many possible embodiments,the fill of the full quantity may trigger a process of monitoringanother trigger associated with the same or a different synthetic orderor submission of another order to the exchange.

Further, it should be understood that in addition to receiving updatesfrom the exchange, the SOM 110 may receive synthetic order updates froma client terminal. For example, if a predetermined synthetic order hasexpired, a trader may wish to resubmit such an order. Alternatively, atrader may wish to delete, replace an existing synthetic order with anew order, or change one or more order parameters such as an orderquantity or a price level to be used as a triggering event, forinstance. When the SOM 110 receives such an update, the SOM 110 mayfirst update the received information in its memory unit and then accessthe data store entity 114 to update the order record corresponding tothe order.

Additionally, a trader may define some synthetic orders to expire on apredetermined date or at a predetermined time during a trading day. Insuch an embodiment, to prevent submission of orders that have expired,the SOM 110 may periodically check for expired orders and delete thoseorders from its memory unit and the data store entity 114. If the SOM110 does not have expiration information related to the orders, the SOM110 may query the data store entity 114 and pull the information relatedto each order from the data store entity 114. Based on the receivedinformation, the SOM 110 may first determine if the retrieved order is atimed order, a good till date order, or a good till day order, forinstance. If the retrieved order is not a timed order, the SOM 110 mayretrieve the next order and perform the same check. If the SOM 110determines that the retrieved order is any of the orders defined aboveor some other timed order, the SOM 110 may determine if the ordersubmission date, order's date, or the order's expiration date was set toan earlier date than the current date. If so, the order has expired, andthe SOM 110 does not initiate sending of such an order to the exchange.

Further, according to one example embodiment, SOMs may use multicast asmeans of discovery for synthetic orders entered via another SOM so thatprocessing of synthetic orders may be load-balanced between a pluralityof SOMs, and other SOMs may seamlessly take over processing of orderswhen one or more SOMs fail. Each SOM may multicast information to otherSOMs upon completion of any action related to a synthetic order so thatall SOMs are synchronized and have up to date information related to aspecific set of orders. For example, a plurality of SOMs may beconfigured to listen for multicasts from each other. Further, each SOMmay be configured with network addresses of other SOMs from which it mayrequest information related to a specific set of orders.

Further, it should be understood that the SOM may be configured with aplurality of SOM groups to which it should send multicast updates, andeach SOM group may be associated with a predetermined set of orders.Alternatively, a multicast message may be sent to all SOMs regardless ofwhether each SOM will receive order updates related to orders that aremanaged at the SOM sending the multicast. Those skilled in the art willunderstand that many other embodiments are possible as well. Further, toprevent failure due to not received multicast information, each SOM mayperiodically query the data store entity 110 to obtain updates onsynthetic orders entered via other SOMs.

Further, the multicast may be used to provide information regardingsynthetic orders entered via another gateway. In such an embodiment, forexample, each SOM associated with a set of gateways may monitor triggersassociated with all orders submitted via the gateways belonging to apredetermined multicast group. However, as explained in reference to thepreceding figures, only the SOM that will access the data store entity114 first, will be able to submit the order to the exchange. It shouldbe understood that multicast is only one method of inter-processcommunications, and different methods could also be used, includingTCIP, or HTML, for example.

Further, if the SOM 110 loses connectivity to the data store entity 114,the SOM 110 may be configured to put all synthetic orders on hold, e.g.,stop monitoring triggers associated with the synthetic orders.Additionally, before putting the orders on hold, the SOM 110 may send amulticast to other SOMs including a query to verify if other SOMs haveaccess to the data store entity 114. If no response is received during apredetermined period of time, the SOM 110 may put all synthetic orderson hold. Once the availability of the data store entity 114 is restored,the SOM 110 may reactivate the orders that have been put on hold. Also,upon reactivating the synthetic orders, the SOM 110 may verify if thestatus of each order has not changed. To do that, the SOM 110 may querythe data store entity 114 to compare the status information. Forinstance, if more than one SOM 110 is capable of submitting the same setof synthetic orders, some orders might have been already submitted byanother SOM upon detecting triggers associated with those orders. Insuch an embodiment, the SOM 110 may remove triggers associated with suchorders from its list of triggers.

Linking and Managing Linked Orders

A trader may link any two orders to create a linked order such as anOCO. A typical OCO known in the art is an order consisting of twoorders, such as a stop order and a limit order, that are submitted tothe same exchange for the same tradable object and for the same orderquantities. Once one of the levels is reached and one half of the OCO(either stop or the limit) is filled, the remaining order (either limitor the stop) associated with the OCO order is cancelled. This type oforder could be fully or partially filled when the market first moves toeither the stop level or the limit level, which causes the other part ofthe order to be cancelled.

According to an example embodiment, a trader may link any two orders togenerate a linked order set. It should be understood that any method ormeans could be used to enable a user to link any two or more orders. Forexample, a graphical selection input could be displayed via the tradinginterface enabling a trader to link any number of orders being input bythe trader. In such an embodiment, when the graphical selection input isenabled, e.g., a user selects the graphical selection input, any neworders being placed by a trader may be linked. Similarly, a trader mayat any time disable linking of the orders by deselecting the graphicalselection input. According to a preferred embodiment, a trader maydynamically modify one or more order parameters in each order bymodifying a single order in the linked order set. For example, the SOM110 may delete all orders that have been linked upon detecting a userinput deleting one of the linked orders. It should be understood thatanother graphical interface could be displayed to a trader, via which atrader may specify which order parameters should be dynamically changedin all linked orders, for example.

Order parameters that can be dynamically updated in a linked order setmay include, among other parameters, an order quantity, or an orderprice level, for example. In such an embodiment, a change in the orderquantity of one of the linked orders may dynamically affect orderquantities of other orders that have been linked to form a linked orderset. For example, if a trader decreases/increases an order quantity inone of the linked orders, the order quantities of the other linkedorders may be dynamically decreased/increased accordingly. In anembodiment in which order quantities of the linked orders are the same,the quantities of the linked orders may be dynamicallydecreased/increased by the same order quantity. Alternatively, if orderquantities of the linked orders are different, and a quantity of one ofthe orders is changed, the change in the order quantities of the otherorders may be proportional to the quantity change in the order that hasbeen modified.

Similarly, instead of changing order quantities, a change in a pricelevel of one of the orders may affect price levels of other orders thathave been linked. For example, if a trader moves one of the linkedorders two ticks down, price levels of other orders that have beenlinked may be dynamically decreased by the equivalent tick level. Forexample, if the linked orders are associated with the same tradableobject, the other linked orders may be moved two ticks down as well.Alternatively, if a linked order set includes orders associated withdifferent tradable objects being traded using different price tickscales, the SOM 110 may determine a new price level for each linkedorder relative to the price level of the order that has beenrepositioned to the new price level. Further, alternatively, and asmentioned in earlier paragraphs, deletion of one of the linked orders ina linked order set may cause the SOM 110 to delete all other linkedorders. It should be understood that different embodiments are possibleas well. For example, only some of the linked orders, the number ofwhich may be user configurable, may be deleted upon detecting a deletionof one of the orders. The following flow chart illustrates one examplemethod that may be performed by the SOM 110 to manage OCOs according toone embodiment.

Further, according to preferred embodiments, a trader is not limited tolinking two orders as an OCO, where each order is associated with thesame tradable object and the same order quantity. According to anexample embodiment, a trader may link any two orders to generate alinked order set that is controlled as OCO. However, unlike the priorart system, the two linked orders may include any user configurableorder types, and may be associated with different tradable objects ordifferent order quantities. If two orders are linked as an OCO and areassociated with different order quantities, the SOM may first determinean order quantity ratio, based on which it may then cancel appropriateorder quantities for one of the orders based on the filled quantitiesreceived for the other linked order. For example, if the quantity ratioof the two linked orders is 2:1, and the SOM receives an update that aquantity of 4 has been filled for the first order, the SOM, based on theratio, may cancel/delete the quantity of 2 for the second order. TheFigures presented hereinafter describe embodiments where the orders aresubmitted to two different exchanges, however, it should be understood,and as mentioned hereinbefore, any two linked orders, such as an OCOhaving different order quantities set for each order, or beingassociated with different tradable objects may be submitted to the sameexchange.

FIG. 7 is a flow chart illustrating a method 700 for linking two ordersas an OCO order and managing order quantities of the two orders uponsubmission of each half of the OCO to a different exchange. According toan example embodiment, the SOM 110 may perform the method 700; however,different embodiments are possible as well. The example method 700includes receiving a linked OCO including a first order and a secondorder at step 702, determining if two orders are to be sent to differentexchanges at step 704, and if so, submitting the first order to a firstexchange at step 706, and submitting the second order to a secondexchange at step 708. The method 700 further includes receiving an orderfill update related to the first order from the first exchange at step710, and at step 712 dynamically adjusting order quantity associatedwith the second order based on the fill update related to the firstorder and received from the first exchange at step 710.

At step 702, the SOM 110 receives a linked OCO request including a firstorder and a second order. According to one embodiment, a trader mayenter an OCO via a graphical interface enabling the trader to enter andlink any two orders and define them as an OCO order pair. It should beunderstood that each half order of the OCO may be associated with thesame or different tradable object being traded at different exchanges,and may include any order type such as a stop, limit or any other userdefined order types. Further, it should be understood that a trader maycontrol when an OCO is entered on the market. For example, a trader mayspecify a predetermined time when the OCO should be entered into themarket. Alternatively, a trader may specify a certain condition, such asreceiving a fill update related to another order, that may triggersubmission of the OCO to the market, the embodiment of which will bedescribed in greater detail below.

If the SOM 110 determines that the OCO is to be submitted to oneexchange, and the exchange supports OCOs, the method 700 for submittingtwo orders to two different exchanges terminates, and the OCO entered bya trader is sent to the exchange. It should be understood that if twolinked orders being part of the OCO are associated with differenttradable objects, the SOM 110 may monitor fill updates for these orders,and update order quantity of the orders alternatively. If the initialorder quantities are different, the SOM 110 may use the quantity numberreceived in the update and the original ratio to determine the quantityto be cancelled in the second linked order. It should be understood thatin an alternative embodiment, if a submission of the OCO is to betriggered by one or more triggering events, the SOM 110 may keepprocessing the order as explained in reference to the preceding figures.For example, the SOM 110 may monitor triggers associated with the OCO,and upon detecting the triggers, the SOM 110 may send the order to theexchange.

Referring back to FIG. 7, if the SOM 110 determines that the ordersassociated with the OCO are to be sent to two different exchanges, theSOM 110 may mark the orders with one or more predetermined identifiersindicating that the orders are linked as an OCO. Using such a method,the SOM 110 can easily detect and extract from data feeds being receivedfrom one or more exchanges data related to the linked orders. Next, atstep 706, the first order may be sent to a first exchange and, at step708, the second order may be sent to a second exchange.

At step 710, the SOM 110 receives a fill update related to the firstorder from the first exchange. For example, the fill update may includeinformation related to a partial fill associated with the first order.Responsively to receiving the fill update, at step 712, the SOM 110 mayadjust the order quantity of the second order based on the received fillupdate information. According to an example embodiment, adjusting theorder quantity of the second order associated with the OCO may includecanceling order quantity of the second order based on the received fillinformation. For example, if the first order is partially filled, andthe two orders forming the OCO have the same order quantities, then thecancelled order quantity is equal to the order quantity that has beenfilled. Alternatively, if the order quantities associated with the twoorders had different quantities, the cancelled order quantity could bedetermined by first determining a percentage change in the orderquantity associated with the first order and then, based on thepercentage change, the SOM 110 could determine the quantity to becancelled for the second order. For example, if 50% of the orderquantity associated with the first order is filled, the SOM 110 maycancel 50% of the order quantity associated with the second order. Itshould be understood that if the SOM 110 receives fill informationrelated to the second order, the SOM 110 may apply the same method tocancel the order quantity associated with the first order.

Further, alternatively, and as mentioned earlier, a trader may define aratio for an OCO order set based on which the quantities of the two halforders associated with the OCO may be determined. For example, a tradermay set up a ratio such as a 2:1 ratio so that the quantity of one halfof the OCO, such as the quantity of a stop order, is twice as high asthe quantity of a limit order. If such a ratio is set by a trader and,once the SOM 110 detects that the quantity associated with one half ofthe OCO has been partially filled, the SOM 110 may determine a quantityto be canceled in the second half order based on the predefined ratio.For example, if an order quantity ratio for an OCO is set to 2:1, where2 corresponds to a limit order and 1 corresponds to a stop order, thenthe quantities of the submitted limit and stop orders may be 20 and 10,respectively. In such an embodiment, if then the quantity of 2associated with the limit order is filled, the SOM 110 may cancel aquantity of 1 of the stop order based on the predefined order quantityratio. It should be understood that if a predetermined order quantity isfilled for one half of an OCO and, based on a predefined ratio, thequantity to be cancelled for the second half of the OCO does notcorrespond to an integer, a rounding algorithm may be used to determinethe quantity to be cancelled in the second half of the OCO.Alternatively, no quantity of the second half of the OCO is canceleduntil an integer quantity can be cancelled, e.g., until a higherquantity of the first half order is filled. It should be understood thatmany different rules and algorithms may be configured to determine orderquantities if, based on the preset ratio, an order quantity to becancelled is not an integer.

Further, it should be understood that in an alternative embodiment, atrader may link an OCO to a third order, and any fill received for thethird order may trigger submission of the OCO to the market. Thefollowing flow chart illustrates an example method that may be performedby the SOM 110 to manage conditional OCOs according to one embodiment.

FIGS. 8A and 8B are a flow chart illustrating a method 800 for linkingmore than two orders and conditional submission of the orders to anexchange according to one embodiment. According to the example method800, an OCO is part of a conditional order set, and the ordersassociated with the OCO are submitted to one or more exchanges uponreceiving fill information related to another order linked to the OCO.In one embodiment, the SOM 110 may perform the method 800; however,different embodiments are possible as well. The example method 800includes receiving a first order linked to an OCO associated with asecond order and a third order at step 802, submitting the first orderto an exchange at step 804, receiving fill information associated withthe first order at step 806, determining order quantity for the secondand third orders based on the fill information received for the firstorder at step 808, submitting the second and third orders to the same ordifferent exchanges at step 810, managing order quantities associatedwith the second and third orders at step 812, determining if the firstorder has been fully filled at step 814, if the order has not been fullyfilled, continuing the method 800 at step 806, and if it is, terminatingthe method 800.

At step 802, the SOM 110 receives a first order linked to an OCOincluding a second order and a third order. According to an exampleembodiment, the OCO is a conditional order and may be submitted to oneor more exchanges upon determining that the first order has beenpartially or fully filled. It should be understood that a trader mayinput and link an OCO with the first order using many different meansincluding a graphical interface enabling the trader to input OCOs and tolink any two or more orders to create a linked order set, for example.Further it should be understood that the OCO may be associated with anytwo linked orders associated with the same or different tradingquantities and tradable objects, that may be submitted to the same ordifferent exchanges.

At step 804, the first order is submitted to an exchange. Responsively,the SOM 110 may start monitoring data feeds being received from theexchange in order to detect fill information related to the first order.At step 806, the SOM 110 receives fill information related to the firstorder, responsively to which the SOM 110 may submit the linked OCO toone or more exchanges. Before submitting the second and third ordersassociated with the OCO to one or more exchanges, at step 808, the SOM110 may determine order quantities for these orders. For example, in oneembodiment, the order quantities for the linked orders may be equal tothe filled order quantity associated with the first order. In such anembodiment, if the SOM 110 detects that the quantity of three has beenfilled for the first order, the order quantities for the second andthird orders may be set to three as well. However, it should beunderstood that different embodiments are possible as well. For example,order quantities associated with the OCO may be different than thefilled order quantity. Further, in one embodiment, the first order maybe associated with an order to buy, while the OCO orders may beassociated with orders to sell, including one stop and one limit sellorder, for example.

Upon determining order quantities for the linked orders based on thefill quantity of the first order, at step 810, the second and thirdorders are submitted to one or more exchanges. At step 812, the SOM 110may monitor fills associated with the second and third orders and updatethe order quantities according to the methods described above. Asexplained in reference to FIG. 7, if the orders are submitted to twodifferent exchanges, the SOM 110 may monitor fill information related tothe orders based on information provided in data feeds from the twoexchanges. Further, since the second and third orders are linked as anOCO, when the SOM 110 receives fill information related to one of theorders, it will automatically decrease the order quantity of the otherlinked order. If the order quantities of the OCO orders are the same,the order quantity that is cancelled may be equal to the order quantitythat has been filled.

At step 814, the SOM 110 determines if the first order has been fullyfilled. If so, the method 800 terminates. Otherwise, the methodcontinues at step 806, where the SOM 110 may receive additionalfill-related information associated with the first order andresponsively may submit more OCO order pairs until the full orderquantity associated with the first order is filled.

In one embodiment, each order entered by a trader may trigger activationof an OCO including a limit order and a stop order that are entered onthe market for every fill quantity detected for the order. Further, atrader may configure a tick value or a price difference between theprice level of the filled order, and a limit and stop linked order pair.Thus, when the SOM 110 detects a fill for the order that has been sentto the exchange, and the order is linked to an OCO, the SOM 110 may thendynamically enter two orders corresponding to the OCO at the pricelevels preconfigured by a trader. For example, a trader may enter a buyorder at 33.50, and then may configure an OCO including a sell stop tobe entered 6 ticks lower than the buy level, thus, stopping loss at30.50, and a sell limit at 6 ticks higher from the buy level, thus,booking profit at 36.50. In such an embodiment, for every fill detectedfor the buy order at 33.50, the SOM 110 may automatically enter a sellstop order at 30.50 and a sell limit order at 36.50. It should beunderstood that the quantities corresponding to the sell stop and selllimit orders may match the quantity of the filled buy order. Forexample, if the SOM 110 detects a fill for 2 corresponding to the buyorder at 33.50, a stop order to sell 2 at 30.50, and a limit order tosell 2 at 36.50 may be sent to the exchange. Similarly, if a tradersends a sell order to an exchange, an OCO including a stop buy and alimit buy may be linked to the sell order. However, it should beunderstood that a trader may control order quantities that should besent for each order, and the order quantities may be different.

Further, in addition to presetting price levels for the linked orders,such as an OCO that is linked to another order, the SOM 110, or anyother application, such as a trading application, may monitor marketmovement and update price levels of each half of the OCO based on themarket movement. For example, a trader may configure a set of rulesdefining price level updates for each linked OCO that may occur upondetecting a predetermined market movement trend. The trader-configuredrules may define conditions defining market movement trends that causelinked orders, such as two orders linked as an OCO, to be moved to newprice levels. For example, upon detecting a downward market trend, atrader-configured rule may keep the two orders associated with the OCOat the same price level. Alternatively, upon detecting an upward markettrend, price levels of the linked orders may be updated to higher levelsaccordingly. In one embodiment, a trader may define a conditional updateof price levels based on market movements. For example, the SOM 110 maymonitor the inside market and allow the inside market to move a presetnumber of ticks up before updating the price level of the linked ordersso that small market fluctuations don't cause the price levels to beupdated continuously. Further, alternatively, only a stop order or alimit order associated with the linked order cancel order pair may bemoved based on the market movement, while the other order may stay atthe same level.

The method for moving orders described above may be beneficial to atrader when the market suddenly shifts, causing one of the orders to befilled when a sudden shift occurs before the orders get moved. However,instead of changing the order prices based on the market movements andupdating the order prices based on a bi-directional market movement, themovement of the orders may be unidirectional and may be based on whetheran OCO is a sell order set or a buy order set that is submitted uponreceiving a fill on a buy or a sell, respectively. For example, if asell order gets filled at the 100-price level, the SOM 110 mayautomatically enter an OCO buy order pair including a buy stop order at103 and a buy limit order at 97. In such an embodiment, the SOM 110 maybe configured to move the OCO order pair upon detecting a downwardmarket trend thus booking the highest profit possible. Using such amethod, if the market moves two ticks down, the two linked orders may bemoved to price levels of 101 and 95, respectively. If the market thenmoves additional 6 ticks down, the orders may be moved to price levelsof 95 and 89, respectively. In such an embodiment, if the marketdirection changes, and the market moves up, the order at the 95 pricelevel will get filled. Thus, such an embodiment is especially beneficialwhen a trader wants to lock his/her wining or maximize profit. It shouldbe understood that when a trader starts with a buy order, the fill ofwhich triggers a sell OCO order pair, the upward market movement maytrigger the OCO sell order pair to follow the upward market trend, thus,once again locking the trader's profit.

Further, alternatively, a trader may define a set of rules that maychange a price level of an order when the order is partially filled. Insuch an embodiment, a trader may define a set of rules so that when apredetermined portion, e.g., a percentage of the original orderquantity, is filled, the remaining order quantity at the original pricelevel may be cancelled, and a new order at a price level different fromthe original price level may be added to the market. For example, a newprice level may be set to a price level that is further away or closerfrom/to the market level than the original price level associated withthe order. For example, a trader may define a number of ticks from theinside market that may be used at the SOM 110 to determine a new pricelevel. Alternatively, the new price level may be based on the markettrend. Further, it should be understood that a trader may control anorder quantity of a new order that is placed on the market when thepartial fill of the original order is detected. For example, the orderquantity for the new order may be set to the order quantity of theoriginal order. Alternatively, the order quantity for the new order maybe set to the remaining order quantity of the partially filled order.

Further, according to another embodiment, a trader may link two or moreorders so that a change in one of the linked orders may be dynamicallyreflected in one or more other linked orders. It should be understoodthat a trader may change one of the order parameters in one of thelinked orders that may then trigger the SOM 110 to automatically reflectthe change in other linked orders. For example, when a trader links twoor more orders, and the SOM 110 detects a change in an order quantity ofone of the linked orders, such as upon receiving a user input decreasingor increasing the order quantity, the SOM 110 may automatically modifyorder quantities in other linked orders accordingly. Based on thediscussion above, it should be understood that the linked orders may beassociated with the same or different tradable objects, order types,order quantities, or exchanges to which the orders have been submitted.Further, for example, a trader may delete one of the linked orders that,when detected by the SOM 110, may cause a deletion of other linkedorders. Additionally, a trader may decide to change a price level of oneof the linked orders, that may in turn cause the movement of otherlinked orders to new price levels. For example, if a trader moves one ofthe linked orders two ticks up, the SOM 110, upon detecting a change,may move other linked orders two ticks up as well. Therefore, using theexample methods, instead of changing order parameters for many ordersindividually, a trader may rather link two or more orders, and thechange in one of such orders may be dynamically reflected in otherlinked orders, thus, saving valuable time and allowing a trader toconcentrate on making other trades.

It should be understood that the above description of the preferredembodiments, alternative embodiments, and specific examples, are givenby way of illustration only and should not be viewed as limiting.Further, many changes and modifications within the scope of the presentembodiments may be made without departing from the spirit thereof, andthe present invention includes such changes and modifications.

Further, it will be apparent to those of ordinary skill in the art thatmethods involved in the system and methods for linking and managinglinked orders in an electronic trading environment may be embodied in acomputer program product that includes one or more computer readablemedia. For example, a computer readable medium can include a readablememory device, such as a hard drive device, a CD-ROM, a DVD-ROM, or acomputer diskette, having computer readable program code segments storedthereon. The computer readable medium can also include a communicationsor transmission medium, such as, a bus or a communication link, eitheroptical, wired or wireless having program code segments carried thereonas digital or analog data signals.

The claims should not be read as limited to the described order orelements unless stated to that effect. Therefore, all embodiments thatcome within the scope and spirit of the following claims and equivalentsthereto are claimed as the invention.

1. (canceled)
 2. A method for managing pending orders, the methodcomprising: submitting a first order for a first tradeable object and asecond order for a second tradeable object from a computing device inresponse to receiving a user command via a user input device associatedwith the computing device, where the second order comprises at least oneparameter determined according to a predetermined relationship betweenthe first tradeable object and the second tradeable object, and wherethe first order is submitted to a first electronic exchange and thesecond order is submitted to a second electronic exchange; receiving,via the computing device, an electronic market data transmission fromthe first electronic exchange for a first updated order parameter forthe first order, the electronic market data transmission being receivedat a first time when both the first order is executable at the firstelectronic exchange and the second order is executable at the secondelectronic exchange; and submitting, via the computing device, an updatemessage to the second electronic exchange to update the second orderwith a second updated order parameter determined according to thepredetermined relationship and the first updated order parameter.
 3. Themethod of claim 2 where the at least one parameter of the second orderis further determined according to at least one parameter of the firstorder.
 4. The method of claim 2 where the first order comprises a firstquantity of a first tradeable object at a first price and the secondorder comprises a second quantity of a second tradeable object at asecond price.
 5. The method of claim 4 where the update messagecomprises any of a cancel command for the second order, a new secondorder for the second tradeable object, an updated second quantity of thesecond tradeable object, and combinations thereof.
 6. The method ofclaim 5 where the updated second quantity is determined according to thepredetermined relationship.
 7. The method of claim 4 further comprisingsubmitting a change message to the second electronic exchange to changethe second quantity in response to a change in the first quantity. 8.The method of claim 7 where the second quantity is changed according tothe predetermined relationship.
 9. The method of claim 7 where thechange message comprises a cancel order for the second order andsubmission of a new second order for a changed second quantity of thesecond tradeable object.
 10. The method of claim 4, further comprisingsubmitting a change message to the second electronic exchange to changethe second quantity in response to a change in the first price.
 11. Themethod of claim 10 where the second quantity is changed according to thepredetermined relationship.
 12. The method of claim 4, furthercomprising submitting a change message to the second electronic exchangeto change the second price in response to a change in the first price.13. The method of claim 12 where the second quantity is changedaccording to the predetermined relationship.
 14. The method of claim 4where the first updated order parameter comprises any of an update tothe first quantity, the first price and combinations thereof.
 15. Themethod of claim 2 where the first electronic exchange is different fromthe second electronic exchange.
 16. The method of claim 2 where thefirst electronic exchange comprises the second electronic exchange. 17.The method of claim 2, further comprising submitting a delete message tothe second electronic exchange to delete the second order executable bythe second electronic exchange in response to any of deletion andcancellation of the first order.
 18. The method of claim 2 where thefirst order is submitted in response to detecting a predeterminedcondition associated with a third order executable at a third electronicexchange.
 19. The method of claim 18 where the predetermined conditioncomprises a fill update associated with the third order.
 20. The methodof claim 19 where the first order comprises a first quantity determinedbased on a filled order quantity identified in the fill update.
 21. Themethod of claim 2 where the predetermined relationship comprises aratio.